home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000008_owner-urn-ietf _Fri Mar 7 23:30:20 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  2KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id XAA19281
  3.     for urn-ietf-out; Fri, 7 Mar 1997 23:30:20 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id XAA19276
  6.     for <urn-ietf@services.bunyip.com>; Fri, 7 Mar 1997 23:30:16 -0500 (EST)
  7. Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA25726  (mail destined for urn-ietf@services.bunyip.com); Fri, 7 Mar 97 23:30:11 -0500
  9. Received: from [18.26.0.235] (gator-macip-6.lcs.mit.edu [18.26.0.235]) by lysithea.lcs.mit.edu (8.6.9/8.6.9) with ESMTP id XAA26595; Fri, 7 Mar 1997 23:30:10 -0500
  10. X-Sender: sollins@ginger.lcs.mit.edu (Unverified)
  11. Message-Id: <v03010d01af4666c53bba@DialupEudora>
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset="us-ascii"
  14. Date: Fri, 7 Mar 1997 19:52:31 -0500
  15. To: urn-ietf@bunyip.com
  16. From: "Karen R. Sollins" <sollins@LCS.MIT.EDU>
  17. Subject: [URN] the othre internet drafts
  18. Sender: owner-urn-ietf@Bunyip.Com
  19. Precedence: bulk
  20. Reply-To: "Karen R. Sollins" <sollins@LCS.MIT.EDU>
  21. Errors-To: owner-urn-ietf@Bunyip.Com
  22.  
  23. Ryan, Ron, Leslie, et al.,
  24.  
  25. The other two internet drafts (draft-ietf-urn-syntax-03.txt and
  26. draft-ietf-urn-http-conv-01.txt) both seem fine to me, with one minor
  27. comment on the latter.  In fact, I have no further comments on the syntax.
  28.  
  29. Perhaps I missed it in the THTTP doc, but otherwise suggest that there
  30. should be a statement somewhere up front that indicates that responses to
  31. such request can in no way be guaranteed to be complete or correct
  32. (although it is in everyone's best interest to do this as much as
  33. possible).  The point is that this protocol makes no statement about the
  34. validity of the responses being sent other than any provisions for
  35. protection of transmitted data.  This is a minor point, but is probably
  36. worth adding to avoid any misunderstandings about correctness or
  37. completeness of the responses.
  38.  
  39.             Karen
  40.  
  41.